Test:

1. Build NetBeans from the target branch
2. Open nbbuild/licenses/Apache-2.0-ASF
3. Mark first word of the document and copy to clipboard
4. Call Clipboard history
5. Repeat steps 3+4 until "ASF" is marked. Ensure that while doing this the NB windows as focus the whole time.

Expected result: All words of the sentence of "Licensed to the Apache Software Foundation (ASF)" should be in the clipboard history as individual entries.

Observed result: No entry in history

Reproduced on:
On github/delivery (acc6180)
Ubuntu 25.04 (with Amazon Corretto 17.0.9.8.1)
Windows 10 (with OpenJDK 24)

Verified on
On f17455c
Same OS/JVM set as reproducer

this is meant to target delivery, right?

Yes

Updated. Given the history I'm not inclined to do much more on this.

making this PR for 26-rc3

changes here seem to make java.editor ClipboardHandlerTest fail often. I can reproduce it locally.
https://github.com/apache/netbeans/actions/runs/14726753775

haven't really looked into it yet

could be harmless, timing changes make a test fail much more often.

Copy/paste works, however the test is sometimes failing when it compares the output before the autoimport-on-paste feature finished.

putting a breakpoint or a 200ms sleep at this spot stabilizes it - I hate the current test stability situation.

actually: this works only while running a single test case, not the full test

edit: NbClipboard itself is asynchronous, the test is assuming copy/paste are blocking operations, see #8476. Essentially the situation as in #8455.

NbClipboard itself is asynchronous, the test is assuming copy/paste are blocking operations,

Which they were. I was curious why returning the copy behaviour to that before #7928 was now causing a test failure. But of course, we're not returning the paste behaviour to the old behaviour, which would have called through NbClipboard::getContents and blocked on the pending change.

I think we need some thought about whether it's desirable to keep the NbClipboard asynchronous behaviour? It could just be for content listening with synchronous behaviour? Or we could force syncing the clipboard in the basekit paste action - https://github.com/apache/netbeans/blob/master/ide/editor.lib/src/org/netbeans/editor/BaseKit.java#L2399 ??

Given that and where we are at with NB26, we might consider it safer to pull this and reconsider for NB27?

Given that and where we are at with NB26, we might consider it safer to pull this and reconsider for NB27?

I would probably also take the safer option and keep it as is for now. Although I couldn't come up with many scenarios where something would programmatically copy things around similar to the unit tests.